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Dear Sir: 

This Second Corrected Appeal Brief is filed in response to the second Notification of 
Non-Compliant Appeal Brief mailed on November 21, 2007. This Brief is filed with a two- 
month Extension of Time. The only changes made in this Corrected Appeal Brief as compared 
to the first Corrected Appeal Brief filed August 1 8, 2007, is that the Related Appeals and 
Interferences section and the Related Proceedings Appendix are updated. Thus, the substantive 
arguments of this Second Corrected Appeal Brief remain the same as the originally-filed Appeal 
Brief of June 5, 2007 and the first Corrected Appeal Brief of August 18, 2007. 
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SECOND CORRECTED APPEAL BRIEF 



The Notification of Non-Compliant Appeal Brief asserts that the Brief fails to list related 
pending appeals filed. The Notification of Non-Compliant Appeal Brief does not, however, 
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provide Appellant any indication as to what related pending appeals should be listed. Upon 
investigation, Appellant has identified 2 potentially related applications that have been and/or are 
currently on appeal before the Board. Thus, Appellant has updated the Related Appeals and 
Interferences section and the Related Proceedings Appendix of this Brief to identify those 
applications. If the Examiner is aware of any further related pending appeals, Appellant 
welcomes the Examiner to identify those for the benefit of Appellant and the Board. 

The fees required under § 41 .20(b)(2) were dealt with in the Appeal Brief filed 
September 19, 2005. 

This brief contains items under the following headings as required by 37 C.F.R. § 41.37 
and M.P.E.P. § 1205.2: 



I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is: 

Hewlett-Packard Development Company, L.P., a Texas Limited Partnership having its 
principal place of business in Houston, Texas. 

II. RELATED APPEALS AND INTERFERENCES 

Appellant respectfully notes that the following co-pending applications are or have been 
previously on appeal before the Board, which may have a bearing on the Board's decision in this 
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appeal: 1} Application No. 10/147,249 ("the '249 Application"); and 2) Application 
No. 09/880,632 ("the '632 Application"). 

An Appeal was filed for the '249 Application, but responsive to the Appeal Brief being 
filed in that application, the Examiner withdrew the rejections at issue and reopened prosecution. 
Accordingly, the appeal was not permitted to advance for consideration, by the Board, and thus 
no decision was rendered by the Board. 

An Appeal was filed for the '632 Application with an Appeal Brief being filed August 
20, 2007. An Examiner's Answer was mailed December 13, 2007. As of this time, no decision 
has been rendered by the Board for the appeal of the '632 Application. 

There are no further appeals, interferences, or judicial proceedings which will, directly 
affect or be directly affected by or have a bearing on the Board's decision in this appeal. 
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III. STATUS OF CLAIMS 

A. Total Number of Claims in Application 
There are 37 claims pending in application. 

B. Current Status of Claims 

1 . Claims canceled: None 

2. Claims withdrawn from consideration but not canceled: None 

3. Claims pending: 1-37 

4. Claims allowed: None 

5. Claims rejected: 1-37 

C. Claims On Appeal. 

The claims on appeal are claims 1-37 
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IV. STATUS OF AMENDMENTS 

A first Office Action was mailed for this application September 22, 2004. In response, 
Applicant filed an Amendment on December 22, 2004, which presented an amendment to claim 
5. A Final Office Action was then mailed April 20, 2005. Applicant did not file an amendment 
in response to the Final Office Action, but instead filed a Notice of Appeal on July 19, 2005 and 
filed a supporting Appeal Brief on September 19, 2005. The rejection at issue in that appeal was 
that all of claims 1-37 stood rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. 
Patent No. 6,775,692 issued to Albert et al ("Albert"). 

In response to such Appeal Brief, the Examiner did not submit an Answer, but instead 
reopened prosecution and mailed an Office Action dated April 6, 2006 which raised a Restriction 
Requirement. Applicant traversed the Restriction Requirement in a response dated May 5, 2006, 
and the Restriction Requirement was withdrawn in an Office Action mailed July 27, 2006. 
However, the July 27, 2006 Office Action rejected the claims on new grounds, namely rejecting 
all of claims 1-37 under 35 U.S.C. § 103(a) as being unpatentable over Albert in view of U.S. 
Patent No. 5,774,660 issued to Brendel et al ("Brendel"). Applicant submitted a response on 
October 25, 2006 which did not amend any of the claims, but instead pointed out that Brendel 
does not correct the deficiencies of Albert that were noted in the previous Appeal. 

A Final Office Action was then mailed January 12, 2007 that maintained the rejection of 
claims 1-37 under 35 U.S.C. § 103(a) as being unpatentable over Albert in view of Brendel, 
Applicant did not file an amendment in response to the Final Office Action, but instead filed a 
Notice of Appeal, which this brief supports. Thus, the claims on appeal are those claims rejected 
in the Final Office Action mailed January 12, 2007, and a listing of those claims are provided in 
Appendix A hereto. 



55191724.1 



5 



Application No,: 09/880,631 



Docket No.: 10010812-1 



V. SUMMARY OF CLAIMED SUBJECT MATTER 

The following provides a concise explanation of the subject matter defined in each of the 
separately argued claims involved in the appeal, referring to the specification by page and line 
number and to the drawings by reference characters, as required, by 37 C.F.R. § 41.37(c)(l)(v). 
Each element of the claims is identified by a corresponding reference to the specification and 
drawings where applicable. Note that the citation to passages in the specification and drawings 
for each claim element does not imply that the limitations from the specification and drawings 
should be read into the corresponding claim element. 

According to one claimed embodiment of the present invention, such as that of 
independent claim 1, a method of TCP state migration in a communication network comprises 
establishing a TCP/IP communication session between a client computer (e.g., client 410 of 
Figure 4) and a first server computer (e.g., server 450 of Figure 4). The first server computer is 
part of a plurality of server computers forming a web cluster containing information (e.g., web 
cluster 490 of Figure 4). The communication session is established for the transfer of data 
contained within the information. The method further comprises handing off the communication 
session to a selected server computer (e.g., server 452 of Figure 4, and see page 23, lines 9-13 of 
the specification) from the first server computer over a persistent control channel using TCP 
handoff modules (e.g.. Upper TCP module 522 and Bottom TCP module 524 of Figure 5C, and 
see page 8, line 25 - page II, line 6, and page 29, line 27 - page 30, line 6 of the specification) 
that are dynamically loadable (see page 17, line 24 - page 18, line 15 of the specification) within 
TCP/IP stacks in operating systems located at both the first server computer and the selected 
server computer, that implement a TCP handoff protocol that works within, kernel levels of an 
existing TCP/IP protocol (see page 23, line 21 - page 26, line 29 of the specification). The 
method further comprises migrat ing a first TCP state of the first server computer to the selected 
server computer, and a second TCP state of the selected server computer to the first server 
computer over the control channel (e.g., page 10, line 26 - page 1 1, line 28 of the specification). 

In one embodiment, such as that of dependent claim 2, establishing the TCP/IP 
communication session further comprises receiving a SYN packet from the client at a first BTCP 
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module located at the first server computer (block 1010 of Figure 10); sending the SYN packet 
upstream to a first TCP module located above the first BTCP module in a first operating system 
of the first server computer (block 1020 of Figure 10); receiving a first SYN/ACK packet from 
the first TCP module (block 1030 of Figure 1 0); parsing the first initial TCP state from the first 
SYN/ACK packet, including a first initial sequence number for the first TCP module associated 
with the TCP/IP communication session (block 1040 of Figure 10); sending the SYN/ACK 
packet to the client (block 1050 of Figure 10); receiving an ACK packet from the client at the 
first BTCP module (block 1060 of Figure 10); sending the ACK packet to the first TCP module 
(block 1070 of Figure 10); receiving, a web request packet associated with the TCP/IP 
communication session at the first BTCP module at the first server computer (block 1080 of 
Figure 10); and storing the SYN, ACK and the web request packet at the first server computer 
(block 1090 of Figure 10). 

In one embodiment, such as that of dependent claim 3, handing off the communication 
session further comprises examining content of the web request packet; determining which of the 
plurality of server computers, a selected server computer, can best process the WEB request 
packet, based on the content (page 10, lines 7-16 of the specification); sending a handoff request 
from said first BTCP module to a second BTCP module at the selected server computer over the 
control channel, if the selected server computer is not the first server computer; including the 
SYN packet and the ACK packet in the handoff request packet; changing a first destination IP 
address of said SYN packet to a second IP address of said selected server computer, at said 
second BTCP module; sending said SYN packet to said second TCP module; receiving a second. 
SYN/ACK packet at said second BTCP module; parsing said second initial TCP state from said 
second SYN/ACK packet, including a second initial sequence number, for said second TCP 
module, that is associated with said TCP/IP communication session; changing a second 
destination IP address of said ACK packet to said second IP address, at said second BTCP 
module; updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; sending said ACK packet that is updated to said second 
TCP module; and sending a handoff acknowledgment message to said first BTCP module. 
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According to another claimed embodiment, such as that of independent claim 1 1, a 
method of TCP state migration in. a communication network comprises establishing a TCP/IP 
communication session between a client computer (e.g., client 410 of Figure 4) and a first server 
computer (e.g., server 450 of Figure 4). The first server computer is part of a plurality of server 
computers forming a web cluster containing information (e.g., web cluster 490 of Figure 4), and 
the communication session is established for the transfer of data contained within the 
information. The method further comprises monitoring traffic associated with establishing said 
TCP/IP communication session to understand a first initial TCP state of the first server computer 
associated with the TCP/IP communication session, at a first bottom-TCP (BTCP) module at the 
first server computer (Bottom TCP module 524 of Figure 5 and BTCP module 830 of Figure 8, 
and see page 9, lines 1 6-20 and page 1 1 . lines 8-11 of the specification). The method further 
comprises receiving a web request associated with the TCP/IP communication session at the first 
BTCP module at the first server computer (block 910 of Figure 9 and block 1310 of Figure 13, 
and see page 10, lines 7-8 of the specification). The method further comprises examining 
content of the web request, and determining which of the pl urality of server computers ("a 
selected server computer") can best process the web request, based on the content (block 930 of 
Figure 9, and see page 10, lines 13-16 of the specification). The method further comprises 
handing off the communication session to the selected server (e.g., server 452 of Figure 4) 
computer from the first server computer over a persistent control channel, if the selected server 
computer is not the first server computer (see page 10, line 26 - page 1 1, line 28 and page 23, 
lines 9-13 of the specification). The method further comprises monitoring traffic associated with 
handing off the TCP/IP communication session to understand a second initial TCP state of the 
selected server computer associated with the TCP/IP communication session, at a second BTCP 
module at the selected server computer (e.g., BTCP module 870 of Figure 8, and see page 12, 
lines 1-13 of the specification). The method further comprises migrating the first initial TCP 
state to the selected server computer over the control channel, such that the second BTCP 
module can calculate a first TCP state for the first server computer in. the TCP/IP communication 
session (e.g., page 12, line 15 - page 13, line 8 of the specification). The method further 
comprises sending a second initial TCP state of the selected server computer to the first BTCP 
module (e.g., BTCP module 830 of Figure 8), such that the first BTCP module can calculate a 
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second TCP state for the selected server computer in the TCP/IP communication session. The 
method further comprises forwarding data packets received at the first BTCP module from the 
client to the selected server computer, by changing the data packets to reflect the second TCP 
state and a second IP address of the selected server computer (e.g., block 1 320 of Figure 1 3, and 
see page 12, line 15 - page 13, line 8 of the specification). The method further comprises 
sending response packets from the selected server computer directly to the client computer (see 
Figures 3 and 4) by changing the response packets to reflect the first TCP state and a first IP 
address of the first server computer (e.g., block 1440 of Figure 14, and see page 12, line 15- page 
13, line 8 of the specification). And, the method further comprises terminating the TCP/IP 
communication session at the first server computer when the TCP/IP communication session is 
closed (e.g., page 13, lines 1.0-19). 

According to another claimed embodiment, such as that of independent claim 26, a server 
computer comprises an upper TCP (UTCP) module (e.g., UTCP module 522 of Figure 5C, and 
UTCP modules 810 and 850 of Figure 8) located above a TCP module (e.g., TCP module 520 of 
Figures 5B and 5C, and TCP modules 820 and 860 in Figure 8) in an operating system of the 
server computer. The server computer further comprises a bottom TCP (BTCP) module (e.g., 
BTCP module 524 of Figure 5C, and BTCP modules 830 and 870 of Figure 8) located below the 
TCP module. The UTCP, TCP, and BTCP modules implement a method of handing off a 
communication session between a first node (e.g., server 450 of Figure 4, and "front-end*' node 
of Figure 8) and second node (e.g., server 452 of Figure 4, and "back-end" node of Figure 8) in a 
cluster network (e.g., cluster 490 of Figure 4) that works within the kernel level of an existing 
TCP/IP protocol, by migrating TCP states associated with the first and second nodes (see page 
10, line 26 - page 12, line 13 of the specification). 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-37 are rejected under 35 U.S.C, § 103(a) as being unpatentable over U.S. Patent. 
No. 6,775,692 issued to Albert et al (hereinafter "Albert") in view of U.S. Patent No. 5,774,660 
issued to Brendel et al. (hereinafter "Brendel"). 

VII. ARGUMENT 

Appellant respectfully traverses the outstanding rejections of the pending claims, and 
requests that the Board reverse the outstanding rejections in light of the remarks contained 
herein. Below, Appellant argues many of the rejected claims separately. Thus, Appellant 
respectfully asserts that separately argued claims do not stand or fall together, see 37 C.F.R. § 
41.37(c)(l)(vii). 

All of claims 1-37 were previously rejected in a Final Office Action mailed April 20, 
2005 as being anticipated under 35 U.S.C. § 102(e) by Albert, In response, Applicant appealed 
the rejection to the Board and submitted an Appeal Brief presenting arguments regarding why 
the claims are not anticipated by Albert, In response to the Appeal Brief, the Examiner has 
reopened prosecution and now rejects the claims as being unpatentable over Albert in view of 
Brendel. 

Appellant respectfully submits that Brendel does not cure the deficiencies of Albert for 
the reasons discussed below. In particular, Brendel is discussed in the Background section of the 
present application (see page 5, line 25 - page 6, line 12 of the present application) and is noted 
as disclosing an inefficient mechanism for transferring TCP states that, requires use of a 
proprietary protocol that is known only to the application level, which embodiments of the 
present invention overcome. Thus, for the reasons discussed further below, the combination of 
Brendel with Albert fails to render the claims unpatentable. As such, Appellant respectfully 
requests that the rejections be overturned and this application be passed to allowance. 

The test for non-obvious subject matter is whether the differences between the subject 
matter and the prior art are such that the claimed subject matter as a whole would have been 
obvious to a person having ordinary skill in the art to which the subject matter pertains. The 
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United States Supreme Court in Graham v. John Deere and Co., 383 U.S. 1 (1966) set forth the 
factual inquiries which must be considered in applying the statutory test: (1) determining of the 
scope and content of the prior art; (2) ascertaining the differences between the prior art and the 
claims at issue; and (3) resolving the level of ordinary skill in the pertinent art. As discussed 
further hereafter, Applicant respectfully asserts that the claims include non-obvious differences 
over the cited art. 

As discussed further below, when considering the scope and content of the applied Albert 
and Brendel references there are significant differences between the applied combination and the 
claims, as the applied combi nation fails to disclose all elements of the claims. Thus, considering 
the lack of disclosure in the applied combination of all elements of the claims, one of ordinary 
skill in the art would not find the claims obvious under 35 U.S.C. §103, and therefore the 
rejections should be overturned. 

Independent Claim 1 

Independent claim 1 recites: 

In a communication network, a method of TCP state migration comprising 
the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a plurality 
of server computers forming a web cluster containing information, said 
communication session established for the transfer of data contained within said 
information; 

b) handing off said communication session to a selected server 
com puter from said first server computer over a persistent control channel using 
TCP handoff modules that are dynamically loadable within TCP/IP stacks in 
operating systems located at both said first server computer and said selected 
server computer, that implement a TCP handoff protocol that works within kernel 
levels of an existing TCP/IP protocol ; and 

c) migrating a first TCP state of said first server computer to said 
selected server computer, and a second TCP state of said selected server computer 
to said first server computer over said control channel. (Emphasis added). 

The combination of Albert and Brendel fails to teach or suggest all elements of 



independent claim 1. For the reasons discussed at length in the Appeal Brief of January 5, 2006, 
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Albert fails to disclose at least: 

A) TCP handoff modules that are dynamically loadable within TCP/IP stacks in operating 
systems located at both said first server computer and said selected server computer; 

B) handing off said communication session; and 

C) a persistent control channel. 

The Final Office Action appears to concede that Albert fails to teach or suggest "b) 
handing off said communication session to a selected, server computer from said first server 
computer over a persistent control channel using TCP handoff modules that are dynamically 
loadable within TCP/IP stacks in operating systems located at both said first server computer and 
said selected server computer, that implement a TCP handoff protocol that works within kernel 
levels of an existing TCP/IP protocol", see page 3 of the Final Office Action, However, the 
Final Office Action asserts that Brendel discloses this element of the claim. Appellant 
respectfully disagrees, as discussed below. 

The present application briefly discusses Brendel at page 5, line 25 - page 6, line 12 as 
follows: 

Previously, various mechanisms for transferring TCP states were 
implemented, including using a separate proprietary protocol at the application 
layer of an operating system. For example, in the Brendel et al. patent (U.S. 
5,774,660), incoming packets to the front-end node have their protocol changed 
from TCP/IP protocol to a non-TCP/IP standard that is only understood by the 
proprietary protocol located at the application layer. Later, the packets are 
changed back to the TCP/IP protocol for transmission to the back-end web server. 
Thus, the Brendel et al. patent reduces processing efficiency by switching back 
and forth between the user-level and kernel level layers of the operating system. 

Thus, a need exists for a more efficient design for implementing a 
mechanism for transferring TCP states in a web server cluster. 

Thus, the present application expressly recognized that Brendel fails to provide TCP 
handoff modules within TCP/IP stacks in operating systems that implement a TCP handoff 
protocol that works within kernel levels of an existing TCP/IP protocol. Instead, Brendel 
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requires that incoming packets be changed into a proprietary protocol that is understood only at 
the application layer. For instance, Brendel explains at col. 13, lines 40-46 thereof: 

Modified TCP/IP stack 82 contains the standard TCP and IP modules with 
some modifications explained later. One modification is that incoming packets 
from the Internet have their protocol changed from TCP to a proprietary "IXP" 
protocol. Since this IXP protocol is unknown to the standard TCP and IP layers, 
it is sent directly up to application layer 80 containing the load balancer. 

Thus, Brendel appears to disclose a system in which the TCP/IP stack of an operating 
system is modified so as to change incoming packets from the TCP protocol to a proprietary 
protocol that is understood only at the application layer, rather than implementing TCP handoff 
modules within the TCP/I P stack to implement a TCP handoff protocol as recited by claim 1 . 

Thus, for at least the above reasons, the combination of Albert and Brendel Mis to 
disclose all elements of claim 1 . As such, the rejection of claim 1 should be overturned, and 
claim 1 should be passed to allowance. 
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Independent Claim 11 

Independent claim 1 1 recites: 

In a communication network, a method of TCP state migration comprising 
the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and a first server computer, said first server computer part of a plurality 
of server computers forming a web cluster containing information, said 
communication session established for the transfer of data contained within said 
information; 

b) monitoring traffic associated with establishing, said TCP/IP 
communication session to understand a first initial TCP state of said first server 
computer associated with said TCP/IP communication session, at a first bottom- 
TCP (BTCP) module at said first server computer; 

c) receiving a web request associated with said TCP/IP 
communication session at said first BTCP module at said first server computer; 

d) examining content of said web request; 

e) determining which of said plurality of server computers, a selected 
server computer, can best process said web request, based on said content; 

fj handing off said communication session to said selected server 
computer from said first server computer over a persistent control channel, if said 
selected server computer is not said first server computer; 

g) monitoring traffic associated with handing off said TCP/IP 
communication session to understand a second initial TCP state of said selected 
server computer associated with said TCP/IP communication session, at a second 
BTCP module at said selected server computer; 

h) migrating said first initial TCP state to said selected server 
computer over said control channel, such that said second BTCP module can 
calculate a first TCP state for said first server computer in said TCP/IP 
communication session; 

i) sending a second initial TCP state of said selected server computer 
to said first BTCP module, such that said first BTCP module can calculate a 
second TCP state for said selected server computer in said TCP/IP 
communication session; 

j) forwarding data packets received at said first BTCP module from 
said client to said selected server computer, by changing said data packets to 
reflect said second TCP state and a second IP address of said selected server 
computer; 

k) sending response packets from said selected server computer 
directly to said client computer by changing said response packets to reflect said 
first TCP state and a first IP address of said first server computer; and 
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1) terminating said TCP/IP communication session at said first server 
computer when said TCP/IP communication session is closed. 

The combination of Albert and Brendel fails to teach or suggest all elements of 
independent claim II. As discussed further in the Appeal Brief of January 5, 2006, Albert fails 
to disclose at least: 

A) a first bottom-TCP (BTCP) module at said first server computer, and a second BTCP 
module at said selected server computer; 

B) examining content of said web request and determining which of said plurality of 
server computers, a selected server computer, can best process said web request, based on said 
content; 

C) sending response packets from said selected server computer directly to said client 
computer; 

D) handing off said communication session; and 

E) a persistent control channel. 

Further, Brendel fails to teach or suggest at least a first bottom-TCP (BTCP) module at 
said first server computer, and a second BTCP module at said selected server computer, as 
recited by claim 1 1 . For instance, as discussed above with claim 1 , Brendel does not teach or 
suggest any such BTCP modules, but instead appears to disclose a modified TCP/IP stack that 
changes an incoming packet's protocol to a proprietary protocol that is unknown to the TCP/IP 
stack for handling at the application level. 

Thus, for at least the above reasons, the combination of Albert and Brendel fails to 
disclose all elements of claim 1 1 . As such, the rejection of claim 1 1 should be overturned, and 
claim 1 1 should be passed to allowance. 
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Independent Claim 26 

Independent claim 26 recites: 

A server computer comprising: 

an upper TCP (UTCP) module located above a TCP module in an 
operating system of said server computer; 

a bottom TCP (BTCP) module located below said TCP module, said 
UTCP, TCP, and BTCP modules implementing a method of handing off a 
communication session between a first node and second node in a cluster network 
that works within the kernel level of an existing TCP/IP protocol, by migrating 
TCP states associated with said first and second nodes. 

The combination of Albert and Brendel fails to teach or suggest all elements of 
independent claim 26. As discussed further in the Appeal Brief of January 5, 2006, Albert fails 
to disclose the recited UTCP and BTCP modules. 

Further, Brendel fails to disclose the UTCP and BTCP modules. For example, Brendel 
does not disclose UTCP, TCP, and BTCP modules that implement a method of handing off a 
communication session between a first node and second node in a cluster network that works 
within the kernel level of an exis ting TC P/IP protocol , as recited by claim 26. For instance, as 
discussed above with claim 1 , Brendel does not disclose any such modules that implement 
handing off a communication session that works within the kernel level of an existing TCP/IP 
protocol, but instead appears to disclose a modified TCP/IP stack that changes an incoming 
packet's protocol to a proprietary protocol that is unknown to the TCP/IP stack for handling at 
the application level. 

Thus, for at least the above reasons, the combination of Albert and Brendel tails to 
disclose all elements of claim 26. As such, the rejection of claim 26 should be overturned, and 
claim 26 should be passed to allowance. 
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Dependent Claim 2 

Claim 2 depends from claim 1 and thus inherits all. elements of claim 1 . Accordingly, 
claim 2 is allowable over the combination of Albert in view of Brendel at least for the reasons 
discussed above with claim 1 . Additionally, claim 2 further recites: 

The method as described in Claim 1 , wherein said step a) comprises the 
steps of: 

receiving a SYN packet from said client at a first BTCP module located at 
said first server computer; 

sending said SYN packet upstream to a first TCP module located above 
said first BTCP module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, 
including a first initial sequence number for said first TCP module associated with 
said TCP/IP communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

receiving a web request packet associated with said TCP/IP 
communication session at said first BTCP module at said first server computer; 

storing said SYN, ACK and said web request packet at said first server 
computer. 

The combination of A lbert in view of Brendel fai ls to disclose all of the further elements 
of claim 2. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 2 (see pages 4-5 of the Final Office Action), as the reasoning for rejecting claim 2 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 2 was rejected as 
being anticipated by Albert), However, Albert fails to disclose all elements of claim 2. For 
instance, Albert fails to disclose at least the recited first BTCP module located at said first server 
computer. Further, Brendel does not appear to be relied upon in the rejection of claim 2 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 2 be overturned. 
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De pendent Claim 3 

Claim 3 depends from claim 2, which depends from claim 1, and thus claim 3 inherits all 
elements of claims 1 and 2. Accordingly, claim 3 is allowable over Albert in view of Brendel at 
least for the reasons discussed above with claims 1 and 2. Additionally, claim 3 further recites: 

The method as described in Claim 2, wherein said step b) comprises the 
steps of: 

examining content of said web request packet ; 

determining which of said plurality of server computers, a selected server 
computer, can best process said WEB request packet, based on said content ; 

sending a handoff request from said first BTCP module to a second BTCP 
module at said selected server computer over said control channel,, if said selected, 
server computer is not said first server computer; 

including said SYN packet and said ACK packet in said handoff request 

packet; 

changing a first destination IP address of said SYN packet to a second IP 
address of said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, 
including a second initial sequence number, for said second TCP module, that is 
associated with said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected 
server computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 

The combination of Albert m view of Brendel fails to disclose all of the further elements 
of claim 3. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 3 (see pages 5-6 of the Final Office Action), as the reasoning for rejecting claim 3 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 3 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim. 3. For 
instance, Albert fails to teach at least the recited second BTCP module at said selected server 
computer. Further, as discussed below with independent claim 11 , Albert fails to teach 
examining content of said web request packet and determining which of said plurality of server 
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computers, a selected server computer, can best process said WEB request packet, based on said 
content . Further, Brendel does not appeal' to be relied upon in the rejection of claim 3 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 3 be overturned. 

Dependent Claim 4 

Claim 4 depends from claim 3, which depends from claim 2 which depends from 1 , and 
thus claim 4 inherits all elements of claims 1, 2, and 3. Accordingly, claim 4 is allowable over 
Albert in view of Brendel at least for the reasons discussed above with claims 1-3. Additionally, 
claim 4 further recites: 

The method as described in Claim 3, wherein step c) comprises the steps 

of: 

monitoring traffic associated with establishing said TCP/IP 
communication session in step a), at said first BTCP module, to parse a first initial 
TCP state of said first server computer, said first initial TCP state associated with 
said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over 
said control channel by including said first initial TCP state in said handoff 
request packet, said first initial TCP state including a first sequence number, such 
that said second BTCP module can calculate said first TCP state for said first 
server computer in said TCP/IP communication session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 4. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 4 (see pages 6-7 of the Final Office Action), as the reasoning for rejecting claim 4 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 4 was rejected as 
being anticipated by A lbert). However, Albert fails to disclose all elements of claim 4. For 
instance, Albert fails to teach at least the recited "migrating said first initial TCP state to said 
second BTCP module over said control channel, by including said first initial TCP state in said 
handoff request packet, said first ini tial TCP state including a first sequence number". Further, 
Brendel does not appear to be relied upon in the rejection of claim 4 as disclosing these elements, 
nor does it do so. 
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Accordingly, Appellant respectfully requests that the rejection of claim 4 be overturned. 
Dependent Claim 5 

Claim 5 depends from claim 3, which depends from claim 2 which depends from 1, and 
thus claim 5 inherits all. elements of claims 3 , 2, and 3. Accordingly, claim 5 is allowable over 
Albert in view of Brendel at least for the reasons discussed above with claims 1-3. Additionally, 
claim 5 further recites: 

The method as described in Claim 3, wherein step c) comprises the steps 

of: 

monitoring traffic associated with handing off said TCP/IP communication 
session at said second BTCP module, to parse a second initial TCP state of said 
selected server computer, said second initial TCP state associated with said 
TCP/IP communication session; and 

migrating said second initial TCP state of said selected server computer to 
said first BTCP module by including said second initial TCP state in said handoff 
acknowledgment packet, said second initial TCP state including a second initial 
sequence number, such that said first BTCP module can calculate said second 
TCP state for said selected server computer in said TCP/IP communication 
session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 5. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 5 (see page 7 of the Final Office Action), as the reasoning for rejecting claim 5 appears to 
be the same as in the Final Office Action of April 20, 2005 (in which claim 5 was rejected as 
being, anticipated by Albert). However, Albert fails to disclose all elements of claim 5. For 
instance, Albert fails to teach at least the recited "migrating said second initial TCP state of said 
selected server computer to said first BTCP module by including said second initial TCP state in 
said handoff acknowledgment packet, said second initial TCP state including a second initial 
sequence number". Further, Brendel does not appear to be relied upon in the rejection of claim 5 
as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 5 be overturned. 
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Dependent Claim 6 

Claim 6 depends from claim 2, which depends from claim 1, and thus claim 6 inherits all 
elements of claims 1 and 2. Accordingly, claim 6 is allowable over Albert in view of Brendel at 
least for the reasons discussed above with claims 1 and 2. Additionally, claim 6 further recites: 

The method as described in Claim 2, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper-TCP 
(UTCP) module, said connection indication message sent by said first TCP 
module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of A lbert in view of Brendel fails to disclose all of the further elements 
of claim 6. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 6 (see pages 7-8 of the Final Office Action), as the reasoning for rejecting claim 6 appears 
to be the same as in the Final Office Action, of April 20, 2005 (in which claim 6 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 6. For 
instance, Albert fails to teach at least the recited first upper TCP UTCP) module. Further, 
Brendel does not appear to be relied upon in the rejection of claim 6 as disclosing these elements, 
nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 6 be overturned. 
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Dependent Claim 7 

Claim 7 depends from claim 6, which depends from claim 2 which depends from claim 1, 
and thus claim 7 inherits all elements of claims 1, 2, and 6. Accordingly, claim 7 is allowable 
over Albert in view of Brendel at least for the reasons discussed above with claims 1, 2, and 6. 
Additionally, claim 7 further recites: 

The method as described in Claim 6, wherein, said method comprises the 
further steps of: 

sending a reset packet from said first BTCP module upon receiving said 
hando ff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 
receiving incoming data packets from said client at said first BTCP 

module; 

changing said destination addresses of said incoming data packets to said 
second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view of Brendel fails to disclose all. of the further elements 
of claim 7. The Final. Office Action appears to rely upon Albert as disclosing all elements of 
claim 7 (see pages 8-9 of the Final Office Action), as the reasoning for rejecting claim 7 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 7 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 7. For 
instance, Albert fails to teach at least the recited "sending a reset packet from said first BTCP 
module upon receiving said handoff acknowledgment packet to said first TCP module". Further, 
Brendel does not appear to be relied upon in the rejection of claim 7 as disclosing these elements, 
nor does it do so. 



Accordingly, Appellant respectfully requests that the rejection of claim 7 be overturned. 
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Dependent Claim 8 

Claim 8 depends from claim 6, which depends from claim 2 which depends from claim 1, 
and thus claim 8 inherits all elements of claims 1, 2, and 6. Accordingly, claim 8 is allowable 
over Albert in view of Brendel at least for the reasons discussed above with claims 1. 2, and 6. 
Additionally, claim 8 further recites: 

The method as described in Claim 6, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP 

module to release said connection indication message, if said selected server 

computer is said first server computer; 

sending incoming data packets, including said web request packet, from. 

said client, received at said first BTCP module, upstream. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 8. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 8 (see page 9 of the Final Office Action), as the reasoning for rejecting claim 8 appears to 
be the same as in the Final Office Action of April 20, 2005 (in which claim 8 was rejected as 
being anticipated by Albert), However, Albert fails to disclose all elements of claim 8. For 
instance, Albert fails to teach at least the recited "sending notification from said first BTCP 
module to said first UTCP module to release said connection indication message, if said selected 
server computer is said first server computer". Further, Brendel does not appear to be relied 
upon in the rejection, of claim 8 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 8 be overturned. 
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Dependent Claim 9 

Claim 9 depends from claim 1. and thus inherits all elements of claim 1. Accordingly, 
claim 9 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1 . Additionally, claim 9 further recites; 

The method as described in Claim l 5 comprising the further step of: 

intercepting outgoing response packets from said selected server computer 
at a second bottom TCP (BTCP) module located at said selected server computer; 

changing source addresses of said response packets to a first IP address of 
said first server computer; 

updating sequence numbers and TCP checksum in said response packets 
to reflect said first TCP state of said first server computer; and 

sending said response packets to said client. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 9. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 9 (see pages 9-10 of the Final Office Action), as the reasoning for rejecting claim 9 
appears to be the same as in the Fi nal Office Action of April 20, 2005 (in which claim 9 was 
rejected as being anticipated by Albert). However, Albert fails to disclose all elements of claim 
9. For instance, Albert fails to teach at least the recited second bottom TCP (BTCP) module 
located at said selected server computer. Further, Brendel does not appear to be relied upon in. 
the rejection of claim 9 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 9 be overturned. 
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Dependent Claim 10 

Claim 10 depends from claim. 1 and thus inherits all elements of claim 1. Accordingly, 
claim 1 0 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1. Additionally, claim 10 further recites: 

The method as described in Claim 1, comprising the further steps of: 
monitoring TCP/IP control traffic for said communication session at said 

second BTCP module; 

understanding when said communication session is closed at said second 

server computer; 

sending a termination message to said first server computer over said 
control channel; 

terminating said TCP/IP communication session at said first server 
computer by terminating a forwarding mode at said first BTCP module; and 

freeing data resources associated with said communication session at said 
first server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 10. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 10 {see page 10 of the Final Office Action), as the reasoning for rejecting claim 10 appears 
to be the same as in the Final Office Action of April 20, 2005 (in which claim 10 was rejected as 
being anticipated by Albert). However, Albert fails to disclose all elements of claim 10. For 
instance, Albert fails to teach at least the recited first and second bottom TCP (BTCP) modules. 
Further, Brendel does not appear to be relied upon, in the rejection of claim 10 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 10 be overturned. 
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Dependent Claim 12 

Claim 12 depends from claim 1 1 and thus inherits all elements of claim 11. Accordingly, 
claim 12 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 11. Additionally, claim 12 further recites: 

The method as described in Claim 1 1 , wherein said step a) comprises the 
steps of: 

receiving a packet from said client at said first BTCP module; 

sending said SYN packet upstream to a first TCP module located above 
said first BTCP module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, 
including a first initial sequence number for said first TCP module associated 
with, said TCP/IP communication session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 

storing said SYN, ACK and said web request at said first server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 12. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 12, as the reasoning for rejecting claim 12 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 12 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 12, For instance, Albert fails to teach at 
least the recited "sending said SYN packet upstream to a first TCP module located above said 
first BTCP module in a first operating system of said first server computer". Further, Brendel 
does not appear to be relied upon in the rejection of claim 12 as disclosing these elements, nor 



Accordingly, Appellant respectfully requests that the rejection of claim 12 be overturned. 
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Dependent Claim 13 

Claim 13 depends from claim 1 1 and thus inherits all elements of claim 11. Accordingly, 
claim 13 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 11. Additionally, claim 13 further recites: 

The method as described in Claim 1 1, wherein said step e) comprises the 
steps of: 

sending a handoff request packet from said first BTCP module to said 
second BTCP module over said, control channel; 

including said SYN packet and said ACK packet in said handoff request 

packet; 

changing a first destination IP address of said SYN packet to a second IP 
address of said selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, 
including a second initial sequence number, for said second TCP module, that is 
associated with said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said second BTCP module; 

updating said ACK packet to reflect, said second TCP state of said selected 
server computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 13. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 13, as the reasoning for rejecting claim 13 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 13 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 13. For instance, Albert fails to teach at 
least the recited "changing a second destination IP address of said ACK packet to said second IP 
address, at said second BTCP module ; . . .and sending a handoff acknowledgment message to 
said first BTCP module " (emphasis added). Further, Brendel does not appear to be relied upon 
in the rejection of claim 13 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 13 be overturned. 
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Dependent Claims 14-15 

Claims 14-15 each depend from claim 13, which depends from claim 11. Thus, claims 
14 and 15 each inherit all elements of claims 1 1 and 13, and are therefore allowable over Albert 
in view of Brendel at least for the reasons discussed above with claims 1 1 and 13. Therefore, 
Appellant respectfully requests that the rejection of claims 14 and 15 be overturned. 

Dependent Claim 16 

Claim 16 depends from claim 13, which depends from claim 11, and thus claim 16 
inherits all elements of claims 1 1 and 13. Accordingly, claim 16 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 1 1 and 13. Additionally, claim 
16 further recites: 

The method as described in Claim 13, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper-TCP 
(UTCP) module, said connection indication message sent by said first TCP 
module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 16. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 16, as the reasoning for rejecting claim 16 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 16 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 16. For instance, Albert fails to teach, at 
least the recited first upper TCP (UTCP) module. Further, Brendel does not appear to be relied 
upon in the rejection of claim 16 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 1 6 be overturned. 
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Dependent Claim 17 

Claim 17 depends from claim 16, which depends from claim 13 which depends from 
claim 1 1, and thus claim 17 inherits all elements of claims 11, 13. and 16. Accordingly, claim 17 
is allowable over Albert in view of Brendel at least for the reasons discussed above with claims 
1.1, 13, and 16. Additionally, claim 1.7 further recites: 

The method as described in Claim 16, wherein step h) comprises the 
further steps of: 

sending a reset packet from said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 
receiving incoming data packets from said client at. said first BTCP 

module; 

changing said destination addresses of said incoming data packets to said 
second IP address; 

updating sequence numbers and TCP checksum, in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 3 7. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 17, as the reasoning for rejecting claim 17 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 1 7 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 17. For instance, Albert fails to teach at 
least the recited "sending a reset, packet from said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module". Further, Brendel does not appear to 
be relied upon in the rejection of claim 17 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 17 be overturned. 
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Dependent Claim 18 

Claim 1 8 depends from claim 1 1 and thus inherits all elements of claim 1 1 . Accordingly, 
claim 3 8 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1 1 . Additionally, claim 1 8 further recites: 

The method as described in Claim 11, wherein step k) comprises the steps 

of: 

intercepting outgoing response packets from said selected server computer 
at said second BTCP module; 

changing source addresses of said response packets to said first IP address; 

updating sequence numbers and TCP checksum in said response packets 
to reflect said first TCP state of said first server computer; and 

sending said updated response packets to said client. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 18. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 18, as the reasoning for rejecting claim 1 8 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 18 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 18. For instance, Albert fails to teach at 
least the recited "intercepting outgoing response packets from said selected server computer at 
said second BTCP module". Further,. Brendel does not appear to be relied upon in the rejection 
of claim 1 8 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 1 8 be overturned. 
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Dependent Claim 19 

Claim 19 depends from claim 1 1 and thus inherits all elements of claim II. Accordingly, 
claim 1.9 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 1 1. Additionally, claim 19 further recites: 

The method as described in Claim 1 1 , wherein step 1) comprises the steps 

of: 

monitoring TCP/IP control traffic for said communication session at said 
second BTCP module; 

understanding when said communication session is closed at said second 
server computer; 

sending a termination message to said first server computer over said 

control channel; 

terminating a forwarding mode at said first BTCP module; and 

freeing data resources associated with said communication session at said 

first server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 1 9. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 19, as the reasoning for rejecting claim 19 appears to be the same as in the Final Office 
Action of April 20 ; 2005 (in which claim 1.9 was rejected as being anticipated by Albert). 
However, Albert tails to disclose all elements of claim 19, For instance, Albert fails to teach at 
least the recited "monitoring TCP/IP control traffic for said communication session at said 
second BTCP module" and "terminating a forwarding mode at said first BTCP module". 
Further, Brendel does not appear to be relied upon in the rejection of claim 19 as disclosing these 
elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 19 be overturned. 



55191124.1 



31 



Application No.: 09/880 f 631 



Docket No.: 10010812-1 



Dependent Claim 20 

Claim 20 depends from claim 16, which depends from claim 13 which depends from 
claim 11, and thus claim. 20 inherits all elements of claims 11, 13, and 16. Accordingly, claim 20 
is allowable over Albert in view of Brendel at least for the reasons discussed above with claims 
1 1, 13, and 16, Additionally, claim 20 further recites: 

The method as described in Claim 1 6, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP 

module to release said connection indication message, if said selected server 

computer is said first server computer; and 

sending incoming data packets, including said web request, from said 

client, received at said first BTCP module, upstream. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 20, The Final Office Action appeal's to rely upon Albert as disclosing all elements of 
claim 20, as the reasoning for rejecting claim 20 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 20 was rejected as being anticipated by Albert). 
However, Albert fails to disclose ail elements of claim 20, For instance, Albert fails to teach at 
least the recited "sending notification from said first BTCP module to said first UTCP module to 
release said connection indication message, if said selected server computer is said first server 
computer". Further, Brendel does not appear to be relied upon in the rejection of claim 20 as 
disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 20 be overturned. 

Dependent Claim 21 

Claim 21 depends from claim 1 1 and thus inherits all elements of claim 11. Accordingly, 
claim 2! is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 11, Additionally, claim 21 further recites: 

The method as described in Claim 11, wherein each of said plurality of 
server computers is constructed similarly including BTCP modules located 
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downstream from TCP modules, and UTCP modules located upstream from TCP 
modules. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 21. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 21, as the reasoning for rejecting claim 21 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 21 was rejected as being anticipated by Albert), 
However, Albert fails to disclose all elements of claim 21 . For instance, Albert fails to teach 
each of its server computers include BTCP modules located downstream from TCP modules, and 
UTCP modules located upstream from TCP modules. Again, Albert foils to teach the recited 
BTCP and UTCP modules. Further, Brendel does not appear to be relied upon in the rejection of 
claim 21 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 21 be overturned. 

De pendent Claim 22 

Claim 22 depends from claim 12, which depends from claim 1. 1 . Thus, claim 22 inherits 
all elements of claims 1 1 and 12, and are therefore allowable oven Albert in view of Brendel at 
least for the reasons discussed above with claims 1 1 and 12. Therefore, Appellant respectfully 
requests that the rejection of claim 22 be overturned. 

Dependent Claim 23 

Claim 23 depends from claim 22, which depends from claim 12 which depends from 
claim 1 1 . Thus, claim. 23 inherits all elements of claims 1 1, 12, and 22. Accordingly, claim 23 
is allowable over Albert in view of Brendel at least for the reasons discussed above with claims 
11, 12, and 22. Additionally, claim 23 further recites: 

The method as described in Claim 22, wherein said control channel allows 
for communication between all UTCP modules. 



55191724.1 



33 



Application No.: 09/880,631 



Docket No.: 10010812-1 



The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 23. The Final Office Action appeal's to rely upon Albert as disclosing all elements of 
claim 23, as the reasoning for rejecting claim 23 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 23 was rejected as being anticipated by Albert). 
However, Albert foils to disclose all elements of claim 23. For instance, Albert fails to teach 
each UTCP modules, and thus fails to teach a control channel that allows communication 
between all of such UTCP modules. Further, Brendel does not appear to be relied upon in the 
rejection of claim 23 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 23 be overturned. 

Dependent Claims 24-25 

Claims 24-25 each depend from claim 11, and thus claims 24 and 25 each inherit all 
elements of claim 1 1 . Therefore, claims 24-25 are each allowable over Albert in view of Brendel 
at least for the reasons discussed above with claim 11. As such, Appellant respectfully requests 
that the rejection of claims 24 and 25 be overturned. 

Dependent Claim 27 

Claim 27 depends from claim 26 and thus inherits all elements of claim 26. Accordingly, 
claim 27 is allowable over Albert in view of Brendel at least for the reasons discussed above with 
claim 26. Additionally, claim 27 further recites: 

The server computer as described in Claim 26, wherein said method 
comprises the steps of: 

a) establishing a TCP/IP communication session between a client 
computer and said server computer, said first node, said server computer part of a 
plurality of server computers forming said cluster network containing 
information, said communication session established for the transfer of data 
contained within said information; 

b) receiving a web request associated with said TCP/IP 
communication session at a first BTCP module at said server computer; 

c) examining content of said web request ; 

d) determining which of said plurality of server computers, a selected 
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server computer, can best process said web request, based on said content ; 

e) handing off said communication session to said selected server 
computer from said server computer over a persistent control channel , if said 
selected server computer is not said server computer; and 

f) migrating a first TCP state of said server computer to said selected 
server computer, and sending a second TCP state of said selected server computer 
to said server computer over said, control channel. (Emphasis added). 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 27. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 27, as the reasoning for rejecting, claim 27 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 27 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 27, For instance, as discussed above with 
claim 1 1 , Albert foils to teach determining which of the plurality of server computers, a selected 
server computer, can best process a web request, based on content of the web request. As also 
discussed above with claim 1 1, Albert fails to teach handing of a communication session over a 
persistent control channel. Further, Brendel does not appeal" to be relied upon in the rejection of 
claim 27 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 27 be overturned. 

Dependent Claim 28 

Claim 28 depends from claim 27, which depends from claim 26, and thus claim 28 
inherits all elements of claims 26 and 27. Accordingly, claim 28 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 27. Additionally, claim 
28 further recites: 

The server computer as described in Claim 27. wherein step a) of said 
method comprises the steps of: 

receiving a SYN packet from said client at said BTCP module; 

sending said SYN packet upstream to said TCP module; 

receiving a first SYN/ACK packet from said TCP module; 

parsing a first initial TCP state from said first SYN/ACK packet, including 
a first initial sequence number for said TCP module associated with said TCP/IP 
communication session; 
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sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said BTCP module; 

sending said ACK packet to said TCP module; 

storing said SYN, ACK at said server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 28. The Final Office Action appears to rely upon Albert: as disclosing all elements of 
claim 28, as the reasoning for rejecting claim 28 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 28 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 28. For instance, as discussed above, 
Albert fails to teach the BTCP module, and thus for at least this reason Albert fails to teach the 
above steps that involve such BTCP module. Further, Brendel does not appear to be relied upon 
in the rejection of claim 28 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 28 be overturned. 

Dependent Claim 29 

Claim 29 depends from claim 28, which depends from claim 27 which depends from 
claim 26, and thus claim 29 inherits all elements of claims 26-28. Accordingly, claim 29 is 
allowable over Albert in view of Brendel at least for the reasons discussed above with claims 26- 
28. Additionally, claim 29 further recites: 

The server computer as described in Claim 28, wherein said method 
comprises the steps of: 

sending a handoff request packet from said BTCP module to a second 
BTCP module over said control channel, said second BTCP module located 
below a second TCP module in a second operating system, at said selected server 
computer; 

including said SYN packet and said. ACK packet in said handoff request; 
receiving a handoff acknowledgment message at said BTCP module from 
said second BTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 29. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 29, as the reasoning for rejecting claim 29 appears to be the same as in the Final Office 
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Action of April 20, 2005 (in which claim 29 was rejected as being anticipated by Albert), 
However, Albert fails to disclose all elements of claim 29. For instance, as discussed above, 
Albert fails to teach the recited BTCP modules, and thus for at least this reason Albert fails to 
teach the above steps that involve such BTCP modules. Further, Brendei does not appear to be 
relied upon in the rejection of claim 29 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 29 be overturned. 

Dependent Claim 30 

Claim 30 depends from claim 29, which depends from claim 28 which depends from 
claim 27 which depends from claim 26, and thus claim 30 inherits all elements of claims 26-29. 
Accordingly, claim 30 is allowable over Albert in view of Brendei at least, for the reasons 
discussed above with claims 26-29. Additionally, claim 30 further recites: 

The server computer as described in Claim 29, wherein said step f) of said 
method comprises the steps of: 

monitoring traffic associated with establishing said TCP/IP 
communication session, in step a), at said BTCP module, to parse a first initial 
TCP state of said server computer, said first initial TCP state associated with said 
TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over 
said control channel by including said first initial TCP state in said handoff 
request, said first initial TCP state including a first sequence number, such that 
said second BTCP module can calculate said first TCP state for said server 
computer in said TCP/IP communication session. 

The combination of Albert in view of Brendei fails to disclose all of the further elements 
of claim 30. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 30, as the reasoning for rejecting claim 30 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 30 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 30. For instance, as discussed above, 
Albert fails to teach the recited BTCP module and control channel, and thus for at least these 
reasons Albert fails to teach the above steps that involve such BTCP modules and control 
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disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 30 be overturned. 
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Dependent Claim 31 

Claim 3 1 depends from claim 29, which depends from claim 28 which depends from 
claim 27 which depends from claim 26, and thus claim 31 inherits all elements of claims 26-29. 
Accordingly, claim 3 1 is allowable over Albert in view of Brendel at least for the reasons 
discussed above with claims 26-29. Additionally, claim 31 further recites: 

The server computer as described in Claim 29, wherein said method 
comprises the further steps of: 

intercepting a connection indication message sent from said first TCP 
module to an application layer above said first TCP module at a first upper-TCP 
(UTCP) module, said connection indication message sent by said first TCP 
module upon establishing said communication session; and 

holding said connection indication message at said first UTCP module. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 31. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 31, as the reasoning for rejecting claim 31 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 31 was rejected as being anticipated by Albert), 
However, Albert fails to disclose, all elements of claim 3 1 . For instance, Albert fails to teach the 
recited first upper TCP (UTCP) module, and thus for at least this reason Albert fails to teach the 
above steps that involve such UTCP module. Further, Brendel does not appear to be relied upon 
in the rejection of claim 3 1 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 31 be overturned. 
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Dependent Claim 32 

Claim 32 depends from claim 31, which depends from claim 29 which depends from 
claim 28 which depends from claim 27 which depends from claim 26,. and thus claim 32 inherits 
all elements of claims 26-29 and 31 . Accordingly, claim 32 is allowable over Albert in view of 
Brendel at least for the reasons discussed above with claims 26-29 and 3 1 . Additionally, claim 
32 further recites: 

The computer system as described in Claim 3 1 , wherein said method 
comprises the further steps of: 

sending a reset packet from said first BTCP module upon receiving said 
handoff acknowledgment packet to said first TCP module; 

discarding said connection indication message at said, first UTCP module; 

receiving incoming data packets from said client at said first BTCP 
module; 

changing said destination addresses of said incoming data packets to said 
second IP address; 

updating sequence numbers and TCP checksum in said data packets to 
reflect said second TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 32. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 32, as the reasoning for rejecting claim 32 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 32 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 32. For instance, Albert fails to teach the 
recited "sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module" and "discarding said connection indication 
message at said first UTCP module". Further, Brendel does not appear to be relied upon in the 
rejection of claim 32 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 32 be overturned. 
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Dependent Claim 33 

Claim 33 depends from claim 31, which depends from claim 29 which depends from 
claim 28 which depends from claim 27 which depends from claim 26 5 and thus, claim 33 inherits 
all elements of claims 26-29 and 3 1 . Accordingly, claim 33 is allowable over Albert in view of 
Brendel at least for the reasons discussed above with claims 26-29 and 3 1 . Additionally, claim 
33 further recites: 

The server computer as described in Claim 3 1 , said method comprising the 
further steps of: 

sending notification from said BTCP module to said UTCP module to 
release said connection indication message, if said selected server computer is 
said sewer computer; 

sending incoming data packets, including said web request, from said 
client, received at said first BTCP module, upstream. 

The combination of Albert in. view of Brendel fails to disclose all of the further elements 
of claim 33. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 33, as the reasoning for rejecting claim 33 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 33 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 33. For instance, Albert fails to teach the 
recited BTCP and UTCP modules, and thus for at least this reason Albert fails to teach the above 
steps involving, such modules. Further, Brendel does not appear to be relied upon in the rejection 
of claim 33 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 33 be overturned. 
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Dependent Claim 34 

Claim 34 depends from claim 26, and thus inherits all elements of claim 26. 
Accordingly, claim 34 is allowable over Albert in view of Brendel at least for the reasons 
discussed above with claim 26. Additionally, claim 34 further recites: 

The server computer as described in Claim 26, said method comprising the 
further steps of: 

receiving a handoff request from a first BTCP module located at a first 
server computer within said cluster network over a persistent control channel, said 
first server computer having established a communication session with a client 
computer, said communication session established for the transfer of data 
contained within said server computer, said handoff request including a SYN 
packet and an ACK packet, said SYN and ACK packet used for establishing said 
communication session between said client and said first server computer, said 
ACK packet including a first initial TCP state of said first server computer in said 
communication session, including a first initial TCP sequence number; 

changing a first destination IP address of said SYN packet to a second IP 
address of said server computer, at said BTCP module; 

sending said SYN packet to said TCP module; 

receiving a SYN/ACK packet at said second BTCP module; 

parsing a second initial TCP state from, second SYN/ACK packet, 
including a second initial sequence number, for said TCP module, said second 
initial TCP state associated with a second TCP state for said server computer in 
said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said 
second IP address, at said BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected 
server computer in said communication session; 

sending said ACK packet that is updated to said TCP module; and 

sending a handoff acknowledgment message to said first BTCP module 
over said control channel. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 34. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 34, as the reasoning for rejecting claim 34 appears to be the same as in the Final Office 
Action of April 20. 2005 (in which, claim 34 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 34. For instance, Albert fails to teach at 
least the recited "receiving a handoff request from a first BTCP module located at a first server 
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computer within said cluster network over a persistent control channel". As discussed above 
with claim 1 1, Albert fails to teach a first BTCP module or a persistent control channel. Further, 
Albert fails to teach a "handoff request". Rather, Albert merely teaches that its forwarding 
agents forward packets to a selected back-end server, rather than handing off the TCP 
communication session. Further, Brendel does not appear to be relied upon in the rejection of 
claim 34 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 34 be overturned. 

Dependent Claim 35 

Claim 35 depends from claim 34, which depends from claim 26, and thus claim 35 
inherits all elements of claims 26 and 34, Accordingly, claim 35 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 34. Additionally, claim 
35 further recites: 

The server computer as described in Claim 34, wherein said method 
comprises the further steps of: 

monitoring traffic associated with handing off said TCP/IP communication 
session to said server computer, at said BTCP module, to parse said second initial 
TCP state of said server computer, said second initial TCP state associated with 
said TCP/IP communication session; and 

sending said second initial TCP state of said server computer to said first 
BTCP module by including said second initial TCP state in said handoff 
acknowledgment, said second initial TCP state including a second initial sequence 
number, such that said first BTCP module can calculate said second TCP state for 
said server computer in said TCP/IP communication session. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 35. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 35, as the reasoning for rejecting claim 35 appears to be the same as in the Final Office 
Action of April 20. 2005 (in which claim 35 was rejected as being anticipated by Albert), 
However, Albert fails to disclose all elements of claim 35. For instance, Albert fails to teach at 
least the recited BTCP module, thus for at least this reason Albert fails to teach the above steps 
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that involve such BTCP module. Further, Brendel does not appear to be relied upon in the 
rejection of claim 35 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 35 be overturned. 

Dependent Claim 36 

Claim 36 depends from claim 34, which depends from claim 26, and thus claim 36 
inherits all elements of claims 26 and 34. Accordingly, claim 36 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 34. Additionally, claim 
36 further recites: 

The server computer as described in Claim 34, wherein said method 
comprises the further steps of: 

intercepting outgoing response packets from said server computer at said 
second BTCP module; 

changing source addresses of said response packets to said first IP address; 

updating sequence numbers and TCP checksum in said response packets 
to reflect said first TCP state of said first server computer; and 

sending said response packets to said client. 

The combination of A lbert in view of Brendel fails to disclose all of the further elements 
of claim 36. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 36, as the reasoning for rejecting claim 36 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 36 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 36. For instance, Albert fails to teach at 
least the recited second BTCP module, thus for at least this reason Albert fails to teach the above 
intercepting step that involves such, second BTCP module. Further, Brendel does not appear to 
be relied upon in the rejection of claim 36 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 36 be overturned. 
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Dependent Claim 37 

Claim 37 depends from claim 34, which depends from claim 26, and thus claim 37 
inherits all elements of claims 26 and 34. Accordingly, claim 37 is allowable over Albert in view 
of Brendel at least for the reasons discussed above with claims 26 and 34. Additionally, claim 
37 further recites: 

The server computer as described in Claim 34, wherein said method 
comprises the further steps of: 

monitoring TCP/IP control traffic for said communication session at said 
BTCP module; 

understanding when said communication session is closed at said server 
computer; and 

sending a termination message to said first server computer over said 
control channel. 

The combination of Albert in view of Brendel fails to disclose all of the further elements 
of claim 37. The Final Office Action appears to rely upon Albert as disclosing all elements of 
claim 37, as the reasoning for rejecting claim 37 appears to be the same as in the Final Office 
Action of April 20, 2005 (in which claim 37 was rejected as being anticipated by Albert). 
However, Albert fails to disclose all elements of claim 37. For instance, Albert fails to teach at 
least the recited BTCP module and control channel, and thus fails to teach the above steps that 
involve such BTCP module and control channel. Further, Brendel does not appear to be relied 
upon in the rejection of claim 37 as disclosing these elements, nor does it do so. 

Accordingly, Appellant respectfully requests that the rejection of claim 37 be overturned. 
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CONCLUSION 

In view of the above, Appellant requests that the board overturn the outstanding 
rejections of claims 1-37. Attached hereto are a Claims Appendix, Evidence Appendix, and 
Related Proceedings Appendix. As noted in the attached Evidence Appendix, no evidence 
pursuant to §§ 1.130, 1.131, or 1.132 or entered, by or relied upon by the examiner is being 
submitted. Also, as noted by the Related Proceedings Appendix, no decisions have been 
rendered by the Board in the identified related proceedings referenced in 0 above, and thus no 
copies of decisions in related proceedings are provided. 

Respectfully submitted, 



By t^-"""" 
Jody.C Bishop -iJ 
Attorney/Agent for Applicant(s) 
Reg. No.: 44,034 
Date: January 28, 2008 
Telephone No. (214) 855-8007 
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APPENDIX A 

Claims Involved in the Appeal of Application Serial No. 09/880,631 

1 . In a communication network^ a method of TCP state migration comprising the 
steps of; 

a) establishing a TCP/IP communication session between a client computer and a 
first server computer, said first server computer part of a plurality of server computers forming a 
web cluster containing information, said communication session established for the transfer of 
data contained within said information: 

b) handing off said communication session to a selected server computer from said 
first server computer over a persistent control channel using TCP handoff modules that are 
dynamically loadable within TCP/IP stacks in operating systems located at both said first server 
computer and said selected server computer, that implement a TCP handoff protocol that works 
within kernel levels of an existing TCP/IP protocol ; and 

c) migrating a first TCP state of said first server computer to said selected server 
computer, and a second TCP state of said selected server computer to said first server computer 
over said control, channel. 

2. The method as described in Claim 1 , wherein said step a) comprises the steps of: 
receiving a SYN packet from said client at a first BTCP module located at said first 

server computer; 

sending said SYN packet upstream to a first TCP module located above said first BTCP 
module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from said first SYN/ACK packet, including a first 
initial sequence number for said first TCP module associated, with said TCP/IP communication 
session; 

sending said SYN/ACK packet to said client; 

receiving an ACK packet from said client at said first BTCP module; 

sending said ACK packet to said first TCP module; 
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receiving a web request packet associated with said TCP/IP communication session at 
said first BTCP module at said first server computer; 

storing said SYN, ACK and said web request packet at said first server computer, 

3, The method as described in Claim 2, wherein said step b) comprises the steps of: 
examining content of said web request packet; 

determining which of said plurality of server computers, a selected server computer, can 
best process said WEB request packet; based on said content; 

sending a handoff request from said first BTCP module to a second BTCP module at said 
selected server computer over said control channel, if said selected server computer is not said 
first server computer; 

including said SYN packet and said ACK packet in said handoff request packet; 

changing a first destination IP address of said SYN packet to a second IP address of said 
selected server computer, at said second BTCP module; 

sending said SYN packet to said, second TCP module; 

receiving a second SYN/ ACK packet at said second BTCP module; 

parsing, said second initial TCP state from said second SYN/ACK packet, including a 
second initial sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session; 

changing a second destination IP address of said ACK packet to said second IP address, 
at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 

sending said ACK packet that is updated to said second TCP module; and 

sending a handoff acknowledgment message to said first BTCP module, 

4. The method as described in Claim 3, wherein step c) comprises the steps of: 
monitoring traffic associated with establishing said TCP/IP communication session in 

step a), at said first BTCP module, to parse a first initial TCP state of said first server computer, 
said first initial TCP state associated with said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over said control 
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channel by including said first initial TCP state in said handoff request packet, said first initial 
TCP state including a first sequence number, such that said second BTCP module can calculate 
said first TCP state for said first server computer in said TCP/IP communication session. 

5. The method as described in Claim 3, wherein step c) comprises the steps of: 
monitoring traffic associated with handing off said TCP/IP communication session at said 

second BTCP module, to parse a second initial TCP state of said selected server computer, said 
second initial TCP state associated with said TCP/IP communication session; and 

migrating said second initial TCP state of said selected server computer to said first 
BTCP module by including said second initial TCP state in said handoff acknowledgment 
packet, said second initial TCP state including a second initial sequence number, such that said 
first BTCP module can calculate said second TCP state for said selected server computer in said 
TCP/IP communication session. 

6. The method as described in Claim 2, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP module to an 

application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
communication session; and 

holding said connection indication message at said first UTCP module. 

7. The method as described in Claim 6, wherein said method comprises the further 
steps of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said second 
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TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer, 

8. The method as described in Claim 6, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP module to release 

said connection indication message, if said selected server computer is said first server computer; 

sending incoming data packets, including said web request packet, from said client, 
received at said first BTCP module, upstream. 

9. The method as described in Claim 1, comprising the further step of: 
intercepting outgoing response packets from said selected server computer at a second 

bottom TCP (BTCP) module located at said selected server computer; 

changing source addresses of said response packets to a first IP address of said first 
server computer; 

updating sequence numbers and TCP checksum in said response packets to reflect said 
first TCP state of said first server computer; and 

sending said response packets to said client. 

1 0. The method as described in Claim 1 , comprising the further steps of: 
monitoring TCP/IP control traffic for said communication session at said second BTCP 

module; 

understanding when said communication session is closed at said second server 
computer; 

sending a termination message to said first server computer over said control channel; 

terminating said TCP/IP communication session at said first server computer by 
terminating a forwarding mode at said first BTCP module; and 

freeing data resources associated with said communication session at said first server 
computer. 

11. In a communication network, a method of TCP state migration comprising the 
steps of: 

a) establishing a TCP/IP communication session between a client computer and a 
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first server computer, said first server computer part of a plurality of server computers forming a 
web cluster containing information, said communication session established for the transfer of 
data contained within said information; 

b) monitoring traffic associated with establishing said TCP/IP communication 
session to understand a first initial TCP state of said first server computer associated with said 
TCP/IP communication session, at a first bottom-TCP (BTCP) module at said first server 
computer; 

c) receiving a web request associated with said TCP/IP communication session at 
said first BTCP module at said first server computer; 

d) examining content of said web request; 

e) determining which of said plurality of server computers, a selected server 
computer, can best process said web request, based on said content; 

f) handing off said communication session to said selected server computer from 
said first server computer over a persistent control channel, if said selected server computer is 
not said first server computer; 

g) monitoring traffic associated with handing off said TCP/IP communication 
session to understand a second initial TCP state of said selected server computer associated with 
said TCP/IP communication session, at a second BTCP module at said selected server computer; 

h) migrating said first initial TCP state to said selected server computer over said 
control channel, such that said second BTCP module can calculate a first TCP state for said first 
server computer in said TCP/IP communication session; 

i) sending a second initial TCP state of said selected server computer to said first 
BTCP module, such that said first BTCP module can calculate a second TCP state for said 
selected server computer in said TCP/IP communication session; 

j) forwarding data packets received at said first BTCP module from said client to 
said selected server computer, by changing said data packets to reflect said second TCP state and 
a second IP address of said selected server computer; 

k) sending response packets from said selected server computer directly to said 
client computer by changing said response packets to reflect said first TCP state and a first IP 
address of said first server computer; and 
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i) terminating said TCP/IP communication session at said first server computer 
when said TCP/IP communication session is closed. 

12. The method as described in Claim 1 1, wherein said step a) comprises the steps of: 
receiving a packet from said client at said first BTCP module; 

sending said SYN packet upstream to a first TCP module located above said first BTCP 
module in a first operating system of said first server computer; 

receiving a first SYN/ACK packet from said first TCP module; 

parsing said first initial TCP state from, said first SYN/ACK packet, including a first 
initial sequence number for said first TCP module associated with, said TCP/IP communication 
session; 

sending said SYN/ACK packet to said client; 
receiving an ACK packet from said client at said first BTCP module; 
sending said ACK packet to said first TCP module; 
storing said SYN, ACK and said web request at said first server computer. 

13. The method as described in Claim 1 1 , wherein said step e) comprises the steps of: 
sending a handoff request packet from said first BTCP module to said second BTCP 

module over said control channel; 

including said SYN packet and said ACK packet in said handoff request packet; 

changing a first destination IP address of said SYN packet to a second IP address of said 
selected server computer, at said second BTCP module; 

sending said SYN packet to said second TCP module; 

receiving a second SYN/ACK packet at said second BTCP module; 

parsing said second initial TCP state from said second SYN/ACK packet, including a 
second initial, sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session; 

changing a second destination IP address of said ACK packet to said second IP address, 
at said second BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 
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sending said ACK packet that is updated to said second TCP module; and 
sending a handoff acknowledgment message to said first BTCP module. 

14. The method as described in Claim 13, wherein said ACK packet includes said 
first initial TCP state of said first server computer as provided for in step f). 

15. The method as described in Claim 13, wherein said handoff acknowledgment 
includes said second initial TCP state of said second server computer, including a second initial 
sequence number, for said second TCP module, that is associated with said TCP/IP 
communication session as provided for in step i). 

1 6. The method as described in. Claim 13, comprising the further steps of: 
intercepting a connection indication message sent from said first TCP module to an 

application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
communication session; and 

holding said connection indication message at said first UTCP module. 

17. The method as described in Claim 16, wherein step h) comprises the further steps 

of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 
receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said second 
TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 



1 8. The method as described, in Claim 1 L wherein step k) comprises the steps of: 
intercepting outgoing response packets from said selected server computer at said second 
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BTCP module; 

changing source addresses of said response packets to said first IP address; 
updating sequence numbers and TCP checksum in said response packets to reflect said 
first TCP state of said first server computer; and 

sending said updated response packets to said client, 

19. The method as described in Claim 1 1, wherein step 1) comprises the steps of: 
monitoring TCP/IP control traffic for said communication session at said second BTCP 

module; 

understanding when said communication session is closed at said second server 
computer; 

sending a termination message to said first server computer over said control channel; 
terminating a forwarding mode at said first BTCP module; and 
freeing data resources associated with said communication session at said first server 
computer. 

20. The method as described in Claim 16, comprising the further steps of: 
sending notification from said first BTCP module to said first UTCP module to release 

said connection indication message, if said selected server computer is said first server computer; 
and 

sending incoming data packets, including said web request, from said client, received at 
said first BTCP module, upstream. 

21 . The method as described in Claim 1 1, wherein each of said plurality of server 
computers is constructed similarly including BTCP modules located downstream from TCP 
modules, and UTCP modules located upstream from TCP modules. 

22. The method as described in Claim 12, comprising the further step of storing said 
web request, said SYN packet, said ACK packet, and said web request at said first server 
computer. 
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23. The method as described, in Claim 22, wherein said control channel allows for 
communication between all UTCP modules. 

24. The method as described in Claim 11, wherein said plurality of server computers 
Is coupled together over a wide area network in said communication network. 

25. The method as described in Claim 11, wherein said information is 
partitioned/partially replicated throughout each of said plurality of server computers. 
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26. A server computer comprising: 

an upper TCP (UTCP) module located above a TCP module in an operating system of 
said server computer; 

a bottom TCP (BTCP) module located below said TCP module, said UTCP, TCP, and 
BTCP modules implementing a method of handing off a communication session between a first 
node and second node in a cluster network that works within the kernel level of an existing 
TCP/IP protocol, by migrating TCP states associated with said first and second nodes. 

27. The. server computer as described in Claim 26, wherein said method comprises 
the steps of: 

a) establishing a TCP/IP communication session between a client computer and said 
server computer, said first node, said server computer part of a plurality of server computers 
forming said cluster network containing information, said communication session established for 
the transfer of data contained within said information; 

b) receiving a web request associated with said TCP/IP communication session at a 
first BTCP module at said server computer; 

c) examining content of said web request; 

d.) determining which of said plurality of server computers,, a selected server 
computer, can best process said web request, based on said content; 

e) handing off said communication session to said selected server computer from 
said server computer over a persistent control channel, if said selected server computer is not 
said server computer; and 

f) migrating a first TCP state of said server computer to said selected server 
computer, and sending a second. TCP state of said selected server computer to said sewer 
computer over said control channel. 

28. The server computer as described in Claim 27, wherein step a) of said method 
comprises the steps of: 

receiving a SYN packet from said client at said BTCP module; 
sending said SYN packet upstream to said TCP module; 
receiving a first SYN/ACK packet from said TCP module; 
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parsing a first initial TCP state from said first SYN/ACK packet, including a first initial 
sequence number for said TCP module associated with said TCP/IP communication session; 
sending said SYN/ACK packet to said client; 
receiving an ACK packet from said client at said BTCP module; 
sending said ACK packet to said TCP module; 
storing said SYN. ACK at said server computer, 

29. The server computer as described in Claim 28, wherein said method comprises 
the steps of: 

sending a handoff request packet from said BTCP module to a second BTCP module over 
said control channel, said second BTCP module located below a second TCP module in a second 
operating system at said selected server computer; 

including said SYN packet and said ACK packet in said handoff request; 

receiving a handoff acknowledgment message at said BTCP module from said second 
BTCP module. 

30. The server computer as described in Claim 29, wherein said step f) of said method 
comprises the steps of: 

monitoring traffic associated with establishing said TCP/IP communication session in 
step a), at said BTCP module, to parse a first initial TCP state of said server computer, said first 
initial TCP state associated with said TCP/IP communication session; and 

migrating said first initial TCP state to said second BTCP module over said control 
channel by including said first initial TCP state in said handoff request, said first initial TCP state 
including a first sequence number, such, that said second BTCP module can calculate said first 
TCP state for said server computer in said TCP/IP communication session. 

3 1 . The server computer as described in Claim 29, wherein said method comprises 
the further steps of: 

intercepting a connection indication message sent from said first TCP module to an 
application layer above said first TCP module at a first upper-TCP (UTCP) module, said 
connection indication message sent by said first TCP module upon establishing said 
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communication session; and 

holding said connection indication message at said first UTCP module, 

32. The computer system as described in Claim 3 1 , wherein said method comprises 
the further steps of: 

sending a reset packet from said first BTCP module upon receiving said handoff 
acknowledgment packet to said first TCP module; 

discarding said connection indication message at said first UTCP module; 

receiving incoming data packets from said client at said first BTCP module; 

changing said destination addresses of said incoming data packets to said second IP 
address; 

updating sequence numbers and TCP checksum in said data packets to reflect said second 
TCP state of said selected server computer; and 

forwarding said data packets to said selected server computer. 

33. The server computer as described in Claim 3 1. said method comprising the further 
steps of: 

sending notification from said BTCP module to said UTCP module to release said 
connection indication message, if said selected server computer is said server computer; 

sending incoming data packets, including said web request, from said client, received at 
said first BTCP module, upstream. 

34. The server computer as described in Claim 26, said, method comprising the further 
steps of: 

receiving a handoff request from a first BTCP module located at a first server computer 
within said cluster network over a persistent control channel, said first server computer having 
established a communication session with a client computer, said communication session 
established for the transfer of data contained within said server computer, said handoff request 
including a SYN packet and an ACK packet, said SYN and ACK packet used for establishing 
said communication session between said client and said first server computer, said ACK packet 
including a first initial TCP state of said first server computer in said communication session, 
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including a first initial TCP sequence number; 

changing a first destination IP address of said SYN packet to a second IP address of said 
server computer, at said BTCP module; 

sending said SYN packet to said TCP module; 

receiving a SYN/ ACK packet at said second BTCP module; 

parsing a second initial TCP state from second SYN/ACK packet, including a second 
initial sequence number, for said TCP module, said second initial TCP state associated with a 
second TCP state for said server computer in said TCP/IP communication session; 

changing a second destination IP address of said ACK packet to said second IP address, 
at said BTCP module; 

updating said ACK packet to reflect said second TCP state of said selected server 
computer in said communication session; 

sending said ACK packet that is updated to said TCP module; and 

sending a handoff acknowledgment message to said first BTCP module over said control 
channel. 

35. The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

monitoring traffic associated with handing off said TCP/IP communication session to 
said server computer, at said BTCP module, to parse said second initial TCP state of said server 
computer, said second initial TCP state associated with said TCP/IP communication session; and 

sending said second initial TCP state of said server computer to said first BTCP module 
by including said second initial TCP state in said handoff acknowledgment, said second initial 
TCP state including a second initial sequence number, such that said first BTCP module can 
calculate said second TCP state for said server computer in said TCP/IP communication session. 

36. The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

intercepting outgoing response packets from said server computer at said second BTCP 
module; 

changing source addresses of said response packets to said first IP address; 
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updating sequence numbers and TCP checksum in said response packets to reflect said 
first TCP state of said first server computer; and 

sending said response packets to said client. 

37. The server computer as described in Claim 34, wherein said method comprises 
the further steps of: 

monitoring TCP/IP control traffic for said communication session at said BTCP module; 
understanding when said communication session is closed at said server computer; and 
sending a termination message to said first server computer over said control channel. 
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APPENDIX B 

No evidence pursuant to §§ 1.130, 1.131, or 1.132 or entered by or relied upon by the 
examiner is being submitted. 
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APPENDIX C 

As referenced in section II above, the following co-pending applications are or have been 
previously on appeal before the Board, which may have a bearing on the Board's decision in this 
appeal: 1) Application No. 10/147.249 ("the '249 Application"); and 2) Application 
No. 09/880,632 ("the '632 Application"). However, no decision of the Board has been rendered 
at this time for either of the above-identified applications, and thus no such decision is provided 
herewith. 

No further related proceedings are referenced in II. above, hence copies of decisions in. 
related proceedings are not provided. 
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